Technical Field
This disclosure relates generally to security within an enterprise computing environment and, in particular, to an identity context-driven approach to control whether users are permitted access to enterprise resources.
Background of the Related Art
Identity is a very key component for defining access control policies in an organization. As numbers of users and applications grow, supporting access control systems that are based on individual identity becomes time-consuming, unwieldy and expensive. To address this problem, it is known in the art to provide role-based access control (RBAC) for enforcing security within an enterprise. In RBAC, security properties, such as access control to sensitive resources, are controlled through roles. Users are assigned one or more roles, who then inherit the security properties associated with the roles. RBAC provides greater security by preventing users from obtaining inconsistent or incompatible security properties. In this approach, a role is a set of permissions that are enabled for an organizational agent that performs certain job functions. A typical RBAC model is based on role names, and assignment of users to those roles. The associated access control is based on these roles. An RBAC-based role typically has meaning only within a given context (i.e., within a Company in which the role is defined, with respect to a given application system used in the Company, or the like).
Role engineering is the process of defining a set of roles for the organization and assigned permissions to those roles. Role engineering may be carried out in a top-down manner, or a bottom-up manner. In a top-down approach, roles are defined by analyzing business processes and identifying the one or more functions that comprise each such process; a set of permissions on information systems are then associated with each function. Typically, the top-down approach begins by defining a job function; a role is then created for this function by associating whatever permissions are needed. Role mining can be used in conjunction with this top-down approach to identify proposed roles that can be examined to determine if that satisfy the business process function to which they might be associated. In contrast, in a bottom-up approach, existing permission assignments are used to formulate roles. Typically, one or more permission assignments are aggregated and associated with a role, and the process may be automated for efficiency.
Role-based access control, while providing benefits, is not always useful because not every group of users to which a policy applies can be translated into a role. Moreover, trying to cover all of the use cases using RBAC often leads to role proliferation and increases the overhead associated with role governance. Moreover, often the definition of a role is not logical, thereby creating additional management difficulties. As an example, assume that the enterprise policies need to be applied to a group of users who are grouped based on an attribute like location, e.g., all people who site in a given city (location) are allowed to enter the office there. Defining a role such as “all people in the city” is not logical, as it is overbroad.
It would be desirable to provide enhanced access control techniques that overcome these and other problems of the prior art.